Concrete Type Inference: Delivering Object-Oriented Applications

types describe properties or invariants of objects. For example, Emerald’s [13] interface types list a set of operations that objects must support and the types of arguments and results of the operations. Abstract types characterize the externally observable behavior of objects and need not distinguish between different implementations of the same behavior. Returning to our example, both ListStack and ArrayStack instances may have an interface type like Stack_IF = [push:elmType→void; pop:void→elmType]†. Stack_IF specifies that objects have a push and a pop operation, but leaves unspecified how these operations are implemented. Any object that defines a push and a pop operation, regardless of how these are implemented, has the abstract type Stack_IF. Smalltalk and Self, while having no linguistic notion of type, nevertheless employ interface types: dynamic type checking in these languages entails verifying that objects “understand” (i.e., define a method for) the messages that they receive. In fact, interfaces are so important that they are introduced on the very first page of Goldberg and Robson’s Smalltalk description [46]. Many statically-typed object-oriented languages, including Simula, Beta, C++, and Eiffel use class types‡. The property that a class type expresses is: “being an instance of the given class or one of its subclasses.” Thus, referring again to the classes in Figure 4, the class type Stack includes instances of the classes Stack, ListStack, and ArrayStack, whereas the class type ArrayStack includes ArrayStack instances only. In fact, for a given program (under the closed-world view discussed in Section 2.1.4), a class type can always be expanded to a concrete type, e.g.: class type Stack = {Stack, ListStack, ArrayStack} class type ArrayStack = {ArrayStack}. We place class types between the concrete types and abstract types in Figure 3. First, class types are not fully abstract: they partially reveal the implementation of objects. For example, if class Stack defines an instance variable size, it can be asserted that any object of class type Stack has this instance variable††. Beta’s “inner” mechanism for method combination [77] likewise implies that methods defined in class Stack extend to any object of class type Stack. Second, class types are not fully concrete; knowing a class type for an object only implies that the specified † This example is not in Emerald syntax. ‡ Other statically-typed languages, including Strongtalk [19] and TOOPL [20], use variations of interface types. †† However, a few languages permit subclasses to override instance variables with get/set methods. Stack ListStack ArrayStack Sequence